Network Working Group G. Gross 
Request for Comments: 2364 Lucent Technologies 
Category: Standards Track M. Kaycee 
Paradyne 

A. Lin 

Shasta Networks 

A. Malis 

Ascend Communications 

J. Stephens 

Cayman Systems 

July 1998 


PPP Over AAL5 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


This document describes the use of ATM Adaptation Layer 5 (AAL5) for 
framing PPP encapsulated packets. 


Applicability 


This specification is intended for those implementations which desire 
to use the facilities which are defined for PPP, such as the Link 
Control Protocol, Network-layer Control Protocols, authentication, 
and compression. These capabilities require a point-to-point 
relationship between the peers, and are not designed for the multi- 
point relationships which are available in ATM and other multi-access 
environments. 
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1. Introduction 


ATM AAL5 protocol is designed to provide virtual connections between 
end stations attached to the same network. These connections offer a 
packet delivery service that includes error detection, but does not 
do error correction. 


Most existing implementations of PPP use ISO 3309 HDLC as a basis for 
their framing [3]. 


When an ATM network is configured with point-to-point connections, 
PPP can use AAL5 as a framing mechanism. 


2. Conventions 


The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
document, are to be interpreted as described in [10]. 


3. AAL5 Layer Service Interface 


The PPP layer treats the underlying ATM AAL5 layer service as a bit- 
synchronous point-to-point link. In this context, the PPP link 
corresponds to an ATM AAL5 virtual connection. The virtual 
connection MUST be full-duplex, point to point, and it MAY be either 
dedicated (i.e. permanent, set up by provisioning) or switched (set 
up on demand). In addition, the PPP/AAL5 service interface boundary 
MUST meet the following requirements: 


Interface Format - The PPP/AAL5 layer boundary presents an octet 
service interface to the AAL5 layer. There is no provision for 
sub-octets to be supplied or accepted. 


Transmission Rate - The PPP layer does not impose any 
restrictions regarding transmission rate or the underlying ATM 
layer traffic descriptor parameters. 


Control Signals - The AAL5 layer MUST provide control signals to 
the PPP layer which indicate when the virtual connection link 
has become connected or disconnected. These provide the "Up" 
and 


"Down" events to the LCP state machine [1] within the PPP layer. 
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4. 


Multi-Protocol Encapsulation 


This specification uses the principles, terminology, and frame 
structure described in "Multiprotocol Encapsulation over ATM 
Adaptation Layer 5" [4]. 


The purpose of this specification is not to document what is already 
standardized in [4], but to specify how the mechanisms described in 
[4] are to be used to map PPP onto an AAL5-based ATM network. 
Section 1 within [4] defines the two mechanisms for identifying the 
Protocol Data Unit (PDU) payload field’s protocol type: virtual 
circuit based multiplexing, and Logical Link Control (LLC) 
encapsulation. In the former technique, the payload’s protocol type 
is implicitly agreed to by the end points for each virtual circuit 
using provisioning or control plane procedures. When using the LLC 
encapsulation technique, the payload’s protocol type is explicitly 
identified on a per PDU basis by an in-band LLC header, followed by 
the payload data. 


When transporting a PPP payload over AAL5, an implementation: 


1. MUST support virtual circuit multiplexed PPP payloads as 
described in section 5 below by mutual configuration or 
negotiation of both end points. This technique is referred to 
as "VC-multiplexed PPP". 


2. MUST support LLC encapsulated PPP payloads on PVCs as 
described in section 6 below by mutual configuration or 
negotiation of both end points. This technique is referred to 
as "LLC encapsulated PPP". 


3. For SVC set up, an implementation MUST negotiate using the 
Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer 
Interface (B-LLI) information element to signal either VC- 
multiplexed PPP or LLC encapsulated PPP. The details of this 
control plane procedure are described in section 7. 


If an implementation is connecting through a Frame Relay/AIM FRF.8 
[7] service inter-working unit to an RFC 1973 [6] end point, then it 
MUST use LLC encapsulated PPP payloads. Frame Relay/ATM FRF.8 
inter-working units are exempted from the requirement to support VC- 
multiplexed PPP. This exemption allows the FR/ATM IWU to remain 
compliant with FRF.8 when the PPP over AAL5 end point is inter- 
operating with an RFC 1973 end point. 


Gross, et. al. Standards Track [Page 3] 


RFC 2364 PPP Over AAL5 July 1998 


5. Virtual Circuit Multiplexed PPP Over AAL5 
The AAL5 PDU format is shown in figure 1: 


AAL5 CPCS-PDU Format 


CPCS-PDU Payload 
up to 2°16 - 1 octets) 


+------------------------------- + 

| PAD ( 0 - 47 octets) | 

+------------------------------- + ------- 

| CPCS-UU (1 octet ) | A 

+------------------------------- + 

| CPI (1 octet ) | 

facesas a reenen +CPCS-PDU Trailer 

| Length (2 octets) | | 

+ ay ee ee ee ee ee 

| CRC (4 octets) | V 

+------------------------------- + ------- 
Figure 1 


The Common Part Convergence Sub-layer (CPCS)-PDU Payload field 
contains user information up to 2%16 - 1 octets. 


The PAD field pads the CPCS-PDU to fit exactly into the ATM cells 
such that the last 48 octet cell payload created by the SAR sublayer 
will have the CPCS-PDU Trailer right justified in the cell. 


The CPCS-UU (User-to-User indication) field is used to transparently 
transfer CPCS user to user information. The field has no function 
under the multi-protocol ATM encapsulation described in this memo and 
can be set to any value. 


The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 
64 bits. Possible additional functions are for further study in 
ITU-T. When only the 64 bit alignment function is used, this field 
shall be coded as 0x00. 


The Length field indicates the length, in octets, of the Payload 
field. The maximum value for the Length field is 65535 octets. A 
Length field coded as 0x00 is used for the abort function. 


The CRC field protects the entire CPCS-PDU except the CRC field 
itself. 
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A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and 
is defined as: 


+ 
| Protocol ID | 
| 8/16 bits | 

+ ese ee ER 
Each of these fields are specifically defined in [1]. 


6. LLC Encapsulated PPP Over AAL5 


LLC encapsulated PPP over AAL5 is the alternative technique to VC- 
multiplexed PPP over AALS. 


The AAL5 CPCS-PDU payload field is encoded as shown in figure 3. 
The pertinent fields in that diagram are: 


1. LLC header: 2 bytes encoded to specify a source SAP and 
destination SAP of routed OSI PDU (values OxFE OxFE), followed 


by an Un-numbered Information (UI) frame type (value 0x03). 


2. Network Layer Protocol IDentifier (NLPID) representing PPP, 
(value OxCF). 


3. the PPP protocol identifier field, which can be either 1 or 2 
octets long. See reference [1]. 


4. followed by the PPP information field as per Figure 2. 
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Pea SSeS SaaS Sees SSS Sess POSSESSES 

| Destination SAP (OxFE) | “ 

+------------------------- + | 

| Source SAP (0xFE) | LLC Wwe 

4------------------------- + 

| Frame Type = UI (0x03) | V 

4------------------------- Hosea Shee 

| NLPID = PPP (OxCF) | 

e E P ocenenie 

| Protocol Identifier | f 

| (8 or 16 bits) | | 

a nn A A + PPP payload 

| | | 

| - | | 

| PPP information field | | 

S Em nE EE E E + 

| padding | v 

EE E 55-55-55 ---------- Pees ssoees 

| PAD ( 0 - 47 octets) | 

E E E : eae 

| CPCS-UU (1 octet ) | f 

+------------------------- + | 

| CPI (1 octet ) | | 

ge Se ee +CPCS-PDU Trailer 

| Length (2 octets) | | 

+ =-= — 

| CRC (4 octets) Vv 

+------------------------- Ai 
Figure 3 


The end points MAY be bi-laterally provisioned to send other LLC- 
encapsulated protocols besides PPP across the same virtual 
connection. However, they MUST NOT send packets belonging to any 
protocol that has an active NCP within the PPP session. 
Implementations SHOULD do packet scheduling that minimizes the 
performance impact on the quality of service commitments associated 
with both the LLC-encapsulated PPP and non-PPP protocol flows. 


7. Out-Of-Band Control Plane Signaling 
When originating a switched virtual circuit AAL5 connection, the 
caller MUST request in the SETUP message either VC-multiplexed PPP, 


LLC-encapsulated PPP, or else both VC-multiplexed and LLC- 
encapsulated PPP. When a caller is offering both techniques, the two 
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B-LLI IEs are encoded within a Broadband Repeat Indicator IE in the 
order of their preference. The called implementation MUST be able to 
accept an incoming call that offers LLC-encapsulated PPP in the 
caller’s request. The called implementation MUST reject a call set 
up request that only offers an encapsulation that it does not 
support. Implementations originating a call offering both protocol 
encapsulation techniques MUST be able to negotiate the use of LLC- 
encapsulated PPP. 


When originating a virtual circuit multiplexed call that is to carry 
a PPP payload, the ITU Q.2931 [9] B-LLI element user information 
layer 3 protocol field is encoded to select ISO/IEC TR 9577 [5] in 
octet 7. The extension octets specify an IPI value of PPP (OxCF). 

By definition, the first bytes of the AAL5 frame’s payload field will 
always contain a PPP header followed by a packet. 


When originating an LLC encapsulated call that is to carry a PPP 
payload, the ITU 9.2931 B-LLI element user information layer 2 
protocol field is encoded to select LAN Logical Link Control 
(ISO/IEC8802-2) in octet 6. See RFC 1755 [8] appendix A for an 
example. By definition, the first bytes of the AALS frame’s payload 
field will contain an LLC header, followed by a NLPID and the PPP 
payload. 


8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions 


When the virtual connection loses state, the PPP encapsulation 
technique may uni-laterally and unexpectedly change across such 
transitions. Detection and recovery procedures are defined for the 
following state transitions: 


vc-multiplexed PPP changing to LLC encapsulated PPP 
LLC encapsulated PPP changing to VC-multiplexed PPP 


When LLC-encapsulated PPP is being used, the inital 6 octets of the 
LCP packets contain the sequence: fe-fe-03-cf-c0-21. This sequence 
constitutes the first 6 octets of the AAL5 frame. In the case of 
VC-multiplexed PPP, initial LCP packets contain the sequence c0-21. 
This sequence constitutes the first 2 octets of an AAL5 frame. When 
a LCP Configure-Request packet is received and recognized, the PPP 
link enters Link Establishment phase. 


Once PPP has entered the Network-layer Protocol phase, and 
successfully negotiated a particular NCP for a PPP Protocol, if a 
frame arrives using an alternate but equivalent data encapsulation as 
defined in [4], then the PPP Link MUST: 
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For a SVC, immediately clear the call with the cause value 111, 
"protocol error, unspecified". 


For a PVC: tear down the active NCPs, SHOULD generate an error 
message, enter the Termination state, and silently drop all 
received packets. 


These policies prevent "black-holes" that occur when the peer loses 
state. An implementation which requires PPP link configuration, and 
other PPP negotiated features (such as authentication), MAY enter 
Termination state when configuration fails. 


9. LCP Configuration Options 


The Magic Number LCP configuration option is RECOMMENDED, and the 
Protocol Field Compression (PFC) option is NOT RECOMMENDED. An 
implementation MUST NOT request any of the following options, and 
MUST reject a request for such an option: 


Field Check Sequence (FCS) Alternatives, 
Address-and-Control-Field-Compression (ACFC), 
Asynchronous-Control-Character-Map (ACCM) 


The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a 
larger size than the maximum CPCS-SDU size specified in the 
associated direction for the virtual connection’s traffic contract. 


When viewed peer to peer, a PPP link may be bridged over multiple 
physical layer sections. For each such AAL5 section, the LCP framing 
options MUST be actively negotiated by the bridging convertors 
independently of the LCP framing options in use by other physical 
layer sections. 


Implementation Note: 
When an ATM AAL5 PVC is in the "Stopped" state, it is 
RECOMMENDED that the implementation wait for Configure-Requests. 
See the implementation option in reference [1] section 4.2, the 
"Stopped State" sub-section. 


10. Security Considerations 


Generally, ATM networks are virtual circuit based, and security is 
implicit in the public data networking service provider’s 
administration of Permanent Virtual Circuits (PVCs) between the 
network boundaries. The probability of a security breach caused by 
mis-—routed ATM cells is considered to be negligible. 
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When a public ATM network supports Switched Virtual Circuits, the 
protocol model becomes analogous to traditional voice band modem dial 
up over the Public Telephone Switched Network (PTSN). The same 
PAP/CHAP authentication protocols that are already widely in use for 
Internet dial up access are leveraged. As a consequence, PPP over 
AAL5 security is at parity with those practices already established 
by the existing Internet infrastructure. 


Those applications that require stronger security are encouraged to 
use authentication headers, or encrypted payloads, and/or ATM-layer 
security services. 


When using LLC-encapsulated PPP over a virtual connection, an end 
point can not assume that the PPP session authentication and related 
security mechanisms also secure the other LLC encapsulated flows on 
that same virtual connection. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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